IETF Logo Mail Archive

[scim] About roles, entitlements, and groups, was ->Re: SCIM Issues

Chris Phillips <Chris.Phillips@canarie.ca> Mon, 16 April 2012 16:00 UTC

Return-Path: <Chris.Phillips@canarie.ca>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD321F8731 for <scim@ietfa.amsl.com>; Mon, 16 Apr 2012 09:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaO6rdsnrxCa for <scim@ietfa.amsl.com>; Mon, 16 Apr 2012 09:00:04 -0700 (PDT)
Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8408021F8725 for <scim@ietf.org>; Mon, 16 Apr 2012 09:00:04 -0700 (PDT)
Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Mon, 16 Apr 2012 12:00:03 -0400
From: Chris Phillips <Chris.Phillips@canarie.ca>
To: "scim@ietf.org" <scim@ietf.org>
Date: Mon, 16 Apr 2012 12:00:02 -0400
Thread-Topic: About roles, entitlements, and groups, was ->Re: [scim] SCIM Issues
Thread-Index: Ac0b6fvUgfuzmjenSZ6xUHtZAj0uDw==
Message-ID: <CBB198A6.9535B%chris.phillips@canarie.ca>
In-Reply-To: <4F8C19E8.2010309@evolveum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [scim] About roles, entitlements, and groups, was ->Re: SCIM Issues
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/scim>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2012 16:00:07 -0000

Hi Radovan (and others),

I've been lurking on the list and it's been great to see the depth that
people are going to on SCIM.

As the contributor for the core schema attributes entitlements and roles
it's not about redundancy and 'can I fit one into the other' it is about
'can I preserve what is intended by roles, groups and entitlements?'.  To
do so needs all these fields.

The original use cases about the differences expressed between groups,
roles, and entitlements are here[1].

Summarized:
	Groups are things you belong to
	Roles are things you are (and implies the assignment of a collection of
entitlements)
	Entitlements are things you have



Implementing SCIM with the schema capable of representing these means not
having to serialize one into the other and then trying to figure out on
the other end what to de-serialize. SCIM is agnostic and preserves the
fidelity of the information regardless of what you are doing with groups,
roles, or entitlements.

The spec does not constrain or exclude anything from any of those 3 fields
because it shouldn't.  Following a certain access control paradigm or
consuming the attributes in a particular fashion once the values are
delivered are up to the implementer to decide what to do next.

Hope this helps...


Chris.
___________________________________________________________________________
________________
Chris Phillips 
Technical Architect, Canadian Access Federation | CANARIE|
chris.phillips@canarie.ca



[1]http://groups.google.com/group/cloud-directory/msg/41d160f6d0edddb6?



On 12-04-16 9:08 AM, "Radovan Semancik" <radovan.semancik@evolveum.com>
wrote:

>And probably the most important one: Both groups and roles can be
>considered entitlements. The groups attribute is read-only, but it can
>be manipulated through Group Resource. Should such group also appear in
>entitlements user attribute? If it cannot than the correct name of that
>attribute should rather be "otherEntitlements" and the specification
>should make that clear. If it can then we have a redundancy: a group can
>be manipulated both through Group Resource and "entitlements" attribute.
>Similarly for roles. The specification does not specify if a role should
>only appear in "roles" and not in "entitlements" or can appear in both.
>The "SCIM Group Schema" also defines that roles may be represented as
>groups, which adds to the confusion. The ignorance of complexity of
>entitlement management was one of the time bombs in SPML. Not it is time
>bomb silently ticking in SCIM.

v2.23.0 | Report a Bug | By Email